1. Technical Field
This disclosure relates generally to securing information in a cloud computing or other shared deployment environment wherein disparate parties share Information Technology (IT) resources.
2. Background of the Related Art
One commonly overlooked component of a traditional computing user experience is based around activity and inactivity. As is well-known, desktop computers dim screens and spin down hard drives to save power, many devices activate password-protected screensavers to prevent passers-by from exploiting an empty desk, and many servers will automatically log out a client that has remained idle for too long. This sort of behavior is generally expected and tolerated by end users, and is often mandated as well by many IT security administrators.
Moving away from the desktop and onto the network, many reverse proxies and gateways also are capable of enforcing inactivity timeouts across all traffic crossing their boundaries. These inactivity monitoring techniques are useful, but they require all of a single user's traffic to flow through a single (logical) device or closely-coupled devices sharing memory state or low-latency network connectivity. Unfortunately, these types of assumptions do not scale naturally into a widely distributed cloud computing environment. As is well-known, cloud computing is an emerging information technology (IT) delivery model by which shared resources, software and information are provided over the Internet to computers and other devices on-demand. A cloud compute environment, such as IBM SmartCloud® for Social Business (formerly known as LotusLive®), presents to the user as a single unified experience; in operation, the end user logs-in once against a centralized authentication component, and then transparently signs-on (e.g., via SAML (Security Assertion Markup Language)-based authentication and authorization techniques) into different components of the service. The different components may run on different subdomains in different physical cages in different data centers in different parts of the world, all running on different hardware with different proxy/gateway/session management capabilities and different back-end technologies. Single clicks on a common “banner bar” can transparently redirect a user between different services without need for separate login, as well as log the user out of all of the components to which he or she has authenticated during that session. In these types of environments, users do not necessarily know (or indeed care) where the back-end servers they are contacting live, because the entire service is being presented to them as a single unified whole. Thus, a user who is actively reading his or her e-mail in one web-based application, for example, would not expect to be logged out of a service being provided by another application to which he or she has been authenticated to during the session.
In a cloud compute environment of this type, it would not be expected that user traffic against a server component hosted, e.g., in a California data center, will not traverse the front-end web proxy used, for example, by a cloud business support service component located elsewhere. Likewise, user traffic against SmartCloud® Notes will never be seen by a reverse proxy for a web-based collaboration tool, such as SmartCloud® Connections. These types of cross-domain operations thus make it extremely difficult to track user activity or inactivity, especially since it may be very likely that a user will become “inactive” with respect to one service while still actively engaged in another service to which he or has been authenticated.
Cross-domain inactivity tracking for web applications that have been integrated in this manner across a cloud compute infrastructure thus presents significant technical challenges. Of course, client-side inactivity monitoring is well-developed in the prior art, as noted above. For example, browser-based cookie scoping and cross-site scripting (XSS) security controls prevent the user's browser from being trivially used to track the user's activity or inactivity state. That said, trusting client-side code to control service-based security, especially across a widely-distributed cloud compute infrastructure, is not an acceptable solution.
Server-side inactivity tracking solutions are also known. Thus, it is known to track inactivity across a set of services linked by common authentication, e.g., using a network authentication server that tracks a common network cookie. On every request, the cookie is updated to maintain a latest activity time. Generally, this approach provides an acceptable solution, but it entails a significant performance overhead due to the need to update the cookie so frequently. Another approach enables an administrator to view display of active sessions, thereby providing an indirect view of inactivity. This approach, however, does not operate in the context of a set of linked services. Finally, it is known in the SAML 2.0 specification to provide a means to specify an inactivity period for each service authenticating to a master authentication service.
These approaches are not scalable and have other inefficiencies. Therefore, there remains a new to provide a new approach to inactivity tracking that can be implemented across disparate compute stacks, such as those implemented by different teams on different technologies, and as may be expected to continue to grow as services of this type grow and incorporates new functionality and new products.